You are viewing the development documentation for the Apereo CAS server. The
functionality presented here is not officially released
yet.
This is a work in progress and will be continually updated as development moves forward. You are
most encouraged to test the changes presented.
As your CAS deployment moves through the deployment pipeline from dev to test and into production
you can manage the configuration between those environments and be certain that applications
have everything they need to run when they migrate through the use of an external configuration server
provided by the Spring Cloud project. As an alternative,
you may decide to run CAS in a standalone mode removing the need for external configuration server deployment,
though at the cost of losing features and capabilities relevant for a cloud deployment.
Configuration Profiles
The CAS server web application responds to the following strategies that dictate how settings should be consumed.
Standalone
This is the default configuration mode which indicates that CAS does NOT require connections to an external configuration server
and will run in an embedded standalone mode. When this option is turned on, CAS by default will attempt to locate settings and properties
inside a given directory and otherwise falls back to using /etc/cas/config as the configuration directory.
You may instruct CAS to use this setting via the methods outlined here.
Similar to the Spring Cloud external configuration server, the contents of this directory include (cas|application).(yml|properties)
files that can be used to control CAS behavior. Also, note that this configuration directory can be monitored by CAS to auto-pick up changes
and refresh the application context as needed. Please review this guide to learn more.
Note that by default, all CAS settings and configuration is controlled via the embedded application.properties file in the CAS server
web application. There is also an embedded application.yml file that allows you to override all defaults if you wish to ship the
configuration inside the main CAS web application and not rely on externalized configuration files. If you prefer
properties to yaml, then application-standalone.properties will override application.properties as well.
Settings found in external configuration files are and will be able to override the defaults provided by CAS. The naming of the configuration files
inside the CAS configuration directory follows the below pattern:
An application.(properties|yml|yaml) file is always loaded, if found.
Settings located inside properties|yml|yaml files whose name matches the value of spring.application.name are loaded (i.e cas.properties) Note: spring.application.name defaults to uppercase CAS but the lowercase name will also be loaded.
Settings located inside properties|yml|yaml files whose name matches the value of spring.profiles.active are loaded (i.e ldap.properties).
Profile-specific application properties outside of your packaged web application (application-{profile}.properties|yml|yaml)
This allows you to, if needed, split your settings into multiple property files and then locate them by assigning their name
to the list of active profiles (i.e. spring.profiles.active=standalone,testldap,stagingMfa)
Configuration files are loaded in the following order where spring.profiles.active=standalone,profile1,profile2. Note
that the last configuration file loaded will override any duplicate properties from configuration files loaded earlier:
If two configuration files with same base name and different extensions exist, they are processed in the order
of properties, yml and then yaml and then groovy (last one processed wins where duplicate properties exist). These
external configuration files will override files located in the classpath (e.g. files from src/main/resources in
your CAS overlay that end up in WEB-INF/classes) but the internal files are loaded per
the Spring Boot rules
which differ from the CAS standalone configuration rules described here (e.g. <profile>.properties
would not be loaded from classpath but application-<profile>.properties would).
Handling Overrides
Remember
You are advised to not overlay or otherwise
modify the built in application.properties or bootstrap.properties files.
This will only complicate and weaken your deployment.
Instead try to comply with the CAS defaults and bootstrap CAS as much as possible via the defaults,
override via application.yml, application-standalone.properties or
use the outlined strategies. Likewise, try to instruct CAS to locate
configuration files external to its own. Premature optimization will only lead to chaos.
The following settings and properties are available from the CAS configuration catalog:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
The configuration settings listed below are tagged as Third Party in the CAS configuration metadata. This flag indicates that the configuration setting is not controlled, owned or managed by the CAS ecosystem, and affects functionality that is offered by a third-party library, such as Spring Boot or Spring Cloud to CAS. For additional info, you might have to visit the third-party source to find more details.
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Spring Cloud
CAS is able to use an external and central configuration server to obtain state and settings.
The configuration server provides a very abstract way for CAS (and all of its other clients) to obtain settings from a variety
of sources, such as file system, git or svn repositories, MongoDb databases, Vault, etc. The beauty of this solution is that to the CAS
web application server, it matters not where settings come from and it has no knowledge of the underlying property sources. It
talks to the configuration server to locate settings and move on.
Configuration Security
This is a very good strategy to ensure configuration settings
are not scattered around various deployment environments leading to a more secure deployment. The configuration server need not be
exposed to the outside world, and it can safely and secure be hidden behind firewalls, etc allowing access to only authorized clients
such as the CAS server web application.
In addition to the strategies outlined here, the configuration server
may load CAS settings and properties via the following order and mechanics:
Profile-specific application properties outside of your packaged web application (application-{profile}.properties|yml)
Profile-specific application properties packaged inside your jar (application-{profile}.properties|yml)
Application properties outside of your packaged jar (application.properties|yml).
Application properties packaged inside your jar (application.properties|yml).
The configuration and behavior of the configuration server is also controlled by its own
src/main/resources/bootstrap.properties file. By default, it runs under port 8888 at /casconfigserver inside
an embedded Apache Tomcat server whose endpoints are protected with basic authentication
where the default credentials are casuser and an auto-generated password defined in src/main/resources/application.properties.
Furthermore, by default it runs under a native profile described below.
The following endpoints are secured and exposed by the configuration server:
Parameter
Description
/encrypt
Accepts a POST to encrypt CAS configuration settings.
/decrypt
Accepts a POST to decrypt CAS configuration settings.
/actuator/refresh
Accepts a POST and attempts to refresh the internal state of configuration server.
/actuator/env
Accepts a GET and describes all configuration sources of the configuration server.
/actuator/cas/default
Describes what the configuration server knows about the default settings profile.
/actuator/cas/native
Describes what the configuration server knows about the native settings profile.
Once you have the configuration server deployed and assuming the credentials used to secure
the configuration server match the example below, you can observe the collection of settings via:
Assuming actuator endpoints are enabled in the configuration, you can also observe
the collection of property sources that provide settings to the configuration server:
Remember that actuator endpoints typically are prefixed with /actuator.
Clients and Consumers
To let the CAS server web application (or any other client for that matter) talk to the configuration server,
the following settings need to be applied to CAS’ own src/main/resources/bootstrap.properties file.
The properties to configure the CAS server web application as the client of the configuration server
must necessarily be read in before the rest of the application’s
configuration is read from the configuration server, during the bootstrap phase.
Remember that configuration server serves property sources from /{name}/{profile}/{label} to applications,
where the default bindings in the client app are the following:
All of them can be overridden by setting spring.cloud.config.* (where * is name, profile or label).
The “label” is useful for rolling back to previous versions of configuration; with the default Config Server implementation
it can be a git label, branch name or commit id. Label can also be provided as a comma-separated list,
in which case the items in the list are tried on-by-one until one succeeds. This can be useful when working on a feature
branch, for instance, when you might want to align the config label with your branch,
but make it optional (e.g. spring.cloud.config.label=myfeature,develop).
To lean more about how CAS allows you to reload configuration changes,
please review this guide.
Profiles
Various profiles exist to determine how configuration server should retrieve properties and settings.
Native
The server is configured by default to load cas.(properties|yml) files from an external location that is /etc/cas/config.
This location is constantly monitored by the server to detect external changes. Note that this location needs to
exist, and does not require any special permissions or structure. The name of the configuration file that goes inside this
directory needs to match the spring.application.name (i.e. cas.properties).
The following settings and properties are available from the CAS configuration catalog:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
The configuration settings listed below are tagged as Third Party in the CAS configuration metadata. This flag indicates that the configuration setting is not controlled, owned or managed by the CAS ecosystem, and affects functionality that is offered by a third-party library, such as Spring Boot or Spring Cloud to CAS. For additional info, you might have to visit the third-party source to find more details.
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
If you want to use additional configuration files, they need to have the
form application-<profile>.(properties|yml).
A file named application.(properties|yml) will be included by default. The profile specific
files can be activated by using the spring.profiles.include configuration option,
controlled via the src/main/resources/bootstrap.properties file:
An example of an external .properties file hosted by an external location follows:
1
cas.server.name=...
You could have just as well used a cas.yml file to host the changes. Note that
the default profile is activated using spring.profiles.active=native.
Default
The configuration server is also able to handle git or svn based repositories that host CAS configuration.
Such repositories can either be local to the deployment, or they could be on the cloud in form of GitHub/BitBucket. Access to
cloud-based repositories can either be in form of a username/password, or via SSH so as long the appropriate keys are configured in the
CAS deployment environment which is really no different than how one would normally access a git repository via SSH.
The following settings and properties are available from the CAS configuration catalog:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
The configuration settings listed below are tagged as Third Party in the CAS configuration metadata. This flag indicates that the configuration setting is not controlled, owned or managed by the CAS ecosystem, and affects functionality that is offered by a third-party library, such as Spring Boot or Spring Cloud to CAS. For additional info, you might have to visit the third-party source to find more details.
spring.cloud.config.server.git.basedir=
Base directory for local working copy of repository.
Override server authentication method order. This should allow for evading login prompts if server has keyboard-interactive authentication before the publickey method.
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Needless to say, the repositories could use both YAML and properties syntax to host configuration files.
The default profile is activated using spring.profiles.active=default.
Keep What You Need!
Again, in all of the above strategies,
an adopter is encouraged to only keep and maintain properties needed for their particular deployment. It is
UNNECESSARY to grab a copy of all CAS settings and move them to an external location. Settings that are
defined by the external configuration location or repository are able to override what is provided by CAS
as a default.
MongoDb
The server is also able to locate properties entirely from a MongoDb instance.
Support is provided via the following dependency in the WAR overlay:
Note that to access and review the collection of CAS properties,
you will need to use your own native tooling for MongoDB to configure and inject settings.
MongoDb documents are required to be found in the collection MongoDbProperty, as the following document:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
Define the password encoder type to use. Type may be specified as blank or NONE to disable password encoding. It may also refer to a fully-qualified class name that implements the Spring Security's PasswordEncoder interface if you wish you define your own encoder. The following types may be used:
NONE: No password encoding (i.e. plain-text) takes place.
DEFAULT: Use the DefaultPasswordEncoder of CAS. For message-digest algorithms via character-encoding and encoding-algorithm.
BCRYPT: Use the BCryptPasswordEncoder based on the strength provided and an optional secret.
SCRYPT: Use the SCryptPasswordEncoder.
PBKDF2: Use the Pbkdf2PasswordEncoder based on the strength provided and an optional secret.
STANDARD: Use the StandardPasswordEncoder based on the secret provided.
SSHA: Use the LdapShaPasswordEncoder supports Ldap SHA and SSHA (salted-SHA). The values are base-64 encoded and have the label {SHA</code> or {SSHA</code> prepended to the encoded hash.
GLIBC_CRYPT: Use the GlibcCryptPasswordEncoder based on the encoding-algorithm, strength provided and an optional secret.
org.example.MyEncoder: An implementation of PasswordEncoder of your own choosing.
file:///path/to/script.groovy: Path to a Groovy script charged with handling password encoding operations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
Strength or number of iterations to use for password hashing. Usually relevant when dealing with PBKDF2 or BCRYPT encoders. Used by GLIBC_CRYPT encoders as well.
The default auto-commit behavior of connections in the pool. Determined whether queries such as update/insert should be immediately executed without waiting for an underlying transaction.
Hibernate feature to automatically validate and exports DDL to the schema. By default, creates and drops the schema automatically when a session is starts and ends. Setting the value to validate or none may be more desirable for production, but any of the following options can be used:
validate: Validate the schema, but make no changes to the database.
update: Update the schema.
create: Create the schema, destroying previous data.
create-drop: Drop the schema at the end of the session.
none: Do nothing.
Note that during a version migration where any schema has changed create-drop will result in the loss of all data as soon as CAS is started. For transient data like tickets this is probably not an issue, but in cases like the audit table important data could be lost. Using `update`, while safe for data, is confirmed to result in invalid database state. validate or none settings are likely the only safe options for production use. For more info, see this.
The database dialect is a configuration setting for platform independent software (JPA, Hibernate, etc) which allows such software to translate its generic SQL statements into vendor specific DDL, DML.
Any value greater than zero will be treated as a timeout for pool initialization. The calling thread will be blocked from continuing until a successful connection to the database, or until the timeout is reached. If the timeout is reached, then a PoolInitializationException will be thrown.
A value of zero will not prevent the pool from starting in the case that a connection cannot be obtained. However, upon start the pool will attempt to obtain a connection and validate that the connectionTestQuery and connectionInitSql are valid. If those validations fail, an exception will be thrown. If a connection cannot be obtained, the validation is skipped and the the pool will start and continue to try to obtain connections in the background. This can mean that callers to DataSource#getConnection() may encounter exceptions.
A value less than zero will not bypass any connection attempt and validation during startup, and therefore the pool will start immediately. The pool will continue to try to obtain connections in the background. This can mean that callers to DataSource#getConnection() may encounter exceptions.
Note that if this timeout value is greater than or equal to zero (0), and therefore an initial connection validation is performed, this timeout does not override the connectionTimeout or validationTimeout; they will be honored before this timeout is applied. The default value is one millisecond.
This property determines whether data source isolates internal pool queries, such as the connection alive test, in their own transaction.
Since these are typically read-only queries, it is rarely necessary to encapsulate them in their own transaction. This property only applies if #autocommit is disabled.
Control global properties that are relevant to Hibernate,
when CAS attempts to employ and utilize database resources,
connections and queries.
cas.jdbc.case-insensitive=false
When choosing physical table names, determine whether names should be considered case-insensitive.
cas.jdbc.gen-ddl=true
Whether to generate DDL after the EntityManagerFactory has been initialized creating/updating all relevant tables.
cas.jdbc.physical-table-names=
Indicate a physical table name to be used by the hibernate naming strategy in case table names need to be customized for the specific type of database. The key here indicates the CAS-provided table name and the value is the translate physical name for the database. If a match is not found for the CAS-provided table name, then that name will be used by default.
cas.jdbc.show-sql=false
Whether SQL queries should be displayed in the console/logs.
If you need to design your own password encoding scheme where the type is specified as a fully
qualified Java class name, the structure of the class would be similar to the following:
If you need to design your own password encoding scheme where the type is
specified as a path to a Groovy script, the structure of the script would be similar to the following:
importjava.util.*byte[]run(finalObject...args){defrawPassword=args[0]defgeneratedSalt=args[1]deflogger=args[2]defcasApplicationContext=args[3]logger.debug("Encoding password...")return...}Booleanmatches(finalObject...args){defrawPassword=args[0]defencodedPassword=args[1]deflogger=args[2]defcasApplicationContext=args[3]logger.debug("Does match or not ?");return...
The following settings and properties are available from the CAS configuration catalog:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
cas.monitor.endpoints.ldap.base-dn=
Base DN to use. There may be scenarios where different parts of a single LDAP tree could be considered as base-dns. Rather than duplicating the LDAP configuration block for each individual base-dn, each entry can be specified and joined together using a special delimiter character. The user DN is retrieved using the combination of all base-dn and DN resolvers in the order defined. DN resolution should fail if multiple DNs are found. Otherwise the first DN found is returned. Usual syntax is: subtreeA,dc=example,dc=net|subtreeC,dc=example,dc=net.
The bind DN to use when connecting to LDAP. LDAP connection configuration injected into the LDAP connection pool can be initialized with the following parameters:
bindDn/bindCredential provided - Use the provided credentials to bind when initializing connections.
bindDn/bindCredential set to * - Use a fast-bind strategy to initialize the pool.
bindDn/bindCredential set to blank - Skip connection initializing; perform operations anonymously.
SASL mechanism provided - Use the given SASL mechanism to bind when initializing connections.
User filter to use for searching. Syntax is cn={user} or cn={0}. You may also provide an external groovy script in the syntax of file:/path/to/GroovyScript.groovy to fully build the final filter template dynamically.
AUTHENTICATED - Manager bind/search type of authentication. If { principalAttributePassword</code> is empty then a user simple bind is done to validate credentials. Otherwise the given attribute is compared with the given principalAttributePassword using the SHA encrypted value of it.
ANONYMOUS: Similar semantics as AUTHENTICATED except no bindDn and bindCredential may be specified to initialize the connection. If principalAttributePassword is empty then a user simple bind is done to validate credentials. Otherwise the given attribute is compared with the given principalAttributePassword using the SHA encrypted value of it.
DIRECT: Direct Bind - Compute user DN from format string and perform simple bind. This is relevant when no search is required to compute the DN needed for a bind operation. Use cases for this type are: 1) All users are under a single branch in the directory, e.g. ou=Users,dc=example,dc=org. 2) The username provided on the CAS login form is part of the DN, e.g. uid=%s,ou=Users,dc=example,dc=org.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
The length of time the pool will block. By default the pool will block indefinitely and there is no guarantee that waiting threads will be serviced in the order in which they made their request. This option should be used with a blocking connection pool when you need to control the exact number of connections that can be created
This settings supports the
java.time.Duration syntax [?].
Removes connections from the pool based on how long they have been idle in the available queue. Prunes connections that have been idle for more than the indicated amount.
This settings supports the
java.time.Duration syntax [?].
Request that the server return results in batches of a specific size. See RFC 2696. This control is often used to work around server result size limits. A negative/zero value disables paged requests.
You may receive unexpected LDAP failures, when CAS is configured to authenticate using DIRECT or AUTHENTICATED types and LDAP is locked down to not allow anonymous binds/searches. Every second attempt with a given LDAP connection from the pool would fail if it was on the same connection as a failed login attempt, and the regular connection validator would similarly fail. When a connection is returned back to a pool, it still may contain the principal and credentials from the previous attempt. Before the next bind attempt using that connection, the validator tries to validate the connection again but fails because it’s no longer trying with the configured bind credentials but with whatever user DN was used in the previous step. Given the validation failure, the connection is closed and CAS would deny access by default. Passivators attempt to reconnect to LDAP with the configured bind credentials, effectively resetting the connection to what it should be after each bind request. Furthermore if you are seeing errors in the logs that resemble a 'Operation exception encountered, reopening connection' type of message, this usually is an indication that the connection pool’s validation timeout established and created by CAS is greater than the timeout configured in the LDAP server, or more likely, in the load balancer in front of the LDAP servers. You can adjust the LDAP server session’s timeout for connections, or you can teach CAS to use a validity period that is equal or less than the LDAP server session’s timeout. Accepted values are:
NONE: No passivation takes place.
BIND: The default behavior which passivates a connection by performing a bind operation on it. This option requires the availability of bind credentials when establishing connections to LDAP.
If principalAttributePassword is empty then a user simple bind is done to validate credentials otherwise the given attribute is compared with the given principalAttributePassword using the SHA encrypted value of it.
For the anonymous authentication type, if principalAttributePassword is empty then a user simple bind is done to validate credentials otherwise the given attribute is compared with the given principalAttributePassword using the SHA encrypted value of it.
Trust Manager options. Trust managers are responsible for managing the trust material that is used when making LDAP trust decisions, and for deciding whether credentials presented by a peer should be accepted. Accepted values are: *
DEFAULT: Enable and force the default JVM trust managers.
Path to the keystore used to determine which certificates or certificate authorities should be trusted. Used when connecting to an LDAP server via LDAPS or startTLS connection. If left blank, the default truststore for the Java runtime is used.
The type of trust keystore that determines which certificates or certificate authorities are trusted. Types depend on underlying java platform, typically PKCS12 or JKS. If left blank, defaults to the default keystore type indicated by the underlying Java platform.
Attribute expected to be found on the entry resulting from the group search whose value is going to be used to construct roles. The final value is always prefixed with #groupPrefix. This is useful in scenarios where you wish to grant access to a resource to all users who a member of a given group.
Attribute expected to be found on the entry whose value is going to be used to construct roles. The final value is always prefixed with #rolePrefix. This is useful in scenarios where you wish to grant access to a resource to all users who carry a special attribute.
The type of search entry handler to choose.
Available values are as follows:
ACTIVE_DIRECTORY: Process the entry results fetched from active directory and
check for account status controls for disabled/expired accounts, etc.
OBJECT_GUID: Object guid search entry handler.
Handles the objectGUID attribute fetching and conversion.
OBJECT_SID: Object sid search entry handler.
Handles the objectSid attribute fetching and conversion.
CASE_CHANGE: Case change search entry handler.
Provides the ability to modify the case of search entry DNs, attribute names, and attribute values.
DN_ATTRIBUTE_ENTRY: DN attribute entry handler.
Adds the entry DN as an attribute to the result set. Provides
a client side implementation of RFC 5020.
MERGE: Merge search entry handler.
Merges the values of one or more attributes into a single attribute.
PRIMARY_GROUP: Primary group search handler.
Constructs the primary group SID and then searches for
that group and puts it's DN in the memberOf attribute of the original search entry.
RANGE_ENTRY: Range entry search handler.
Rewrites attributes returned from Active Directory to
include all values by performing additional searches.
RECURSIVE_ENTRY: Recursive entry search handler.
This recursively searches based on a supplied
attribute and merges those results into the original entry.
MERGE_ENTRIES: Merge entries handler.
Merges the values of one or more attributes in all entries into a single attribute. The merged attribute may or may not already
exist on the entry. If it does exist it's existing values will remain intact.
Determine the LDAP validator type. The following LDAP validators can be used to test connection health status:
search: Validates a connection is healthy by performing a search operation. Validation is considered successful if the search result size is greater than zero.
none: No validation takes place.
compare: Validates a connection is healthy by performing a compare operation.
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
The login context name should coincide with a given index in the login config specified. This name is used as the index to the configuration specified in the login config property.
CAS, being a Spring-Boot application at heart, includes a number of endpoints to help you monitor and manage the server when it’s pushed to production. You can choose to manage and monitor the deployment using HTTP endpoints, referred to as actuators.
In essence, actuator endpoints bring production-ready features to CAS. Monitoring a running CAS instance, gathering metrics, understanding traffic or the state of our database becomes trivial with such endpoints. The main benefit of these endpoints is that we can get production grade tools without having to actually implement these features ourselves. Actuators are mainly used to expose operational information about the running application – health, metrics, etc. These are HTTP endpoints or JMX beans to enable us to interact with it.
Actuator endpoints are presented by CAS in two categories:
Those that are owned and defined by the CAS project.
Those that are owned and defined by third-party projects, frameworks and libraries such as Spring Boot.
Exposed Endpoints
Note that by default the only endpoints exposed over the web
are info, status, health and configurationMetadata.
Other endpoints need to be explicitly enabled and then
exposed over the web in CAS settings in order to allow access.
To enable and expose an actuator endpoint:
1
2
3
4
5
management.endpoint.consul.enabled=truemanagement.endpoints.web.exposure.include=consul# Choose the proper security access level...
# cas.monitor.endpoints.endpoint.consul.access=PERMIT
The following settings and properties are available from the CAS configuration catalog:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
cas.monitor.endpoints.form-login-enabled=false
Control whether access to endpoints can be controlled via form-based login over the web via a special admin login endpoint.
Whether unique runtime object names should be ensured.
Deprecation status is ERROR
with a replacement setting: spring.jmx.unique-names.
management.endpoints.migrate-legacy-ids=false
Whether to transparently migrate legacy endpoint IDs.
management.endpoints.web.base-path=/actuator
Base path for Web endpoints. Relative to the servlet context path (server.servlet.context-path) or WebFlux base path (spring.webflux.base-path) when the management server is sharing the main server port. Relative to the management server base path (management.server.base-path) when a separate management server port (management.server.port) is configured.
Comma-separated list of origin patterns to allow. Unlike allowed origins which only supports '*', origin patterns are more flexible (for example 'https://*.example.com') and can be used when credentials are allowed. When no allowed origin patterns or allowed origins are set, CORS support is disabled.
Comma-separated list of origins to allow. '*' allows all origins. When credentials are allowed, '*' cannot be used and origin patterns should be configured instead. When no allowed origins or allowed origin patterns are set, CORS support is disabled.
For basic authentication, the default username is casuser. The password may be automatically generated at startup and displayed in CAS logs if it is left undefined in CAS settings. Additional sources may also be defined that would authenticate the request via JAAS, LDAP, JDBC, etc.
Once endpoints are enabled and exposed, the security of all provided endpoints
is handled
by the Spring Security
project.
Protection and access to each endpoint
is controlled via CAS settings individually such that you may
decide a specific security level and method of authentication for each endpoint
independently.
If CAS is configured to NOT enforce endpoint security
rules, then
all endpoints are considered sensitive and require authentication, typically
handled
via basic authentication with master credentials defined in CAS settings.
If CAS is configured to enforce endpoint security rules, then each
endpoint may be tagged with a specific security rule allowing access via
authorized IP addresses,
basic credentials, roles and attributes, etc.
Defaults
There is a special endpoint named defaults which serves as a shortcut that
controls the security of all endpoints, if left undefined in CAS settings.
To enable additional logging, configure the log4j configuration file to add the
following levels:
To see the relevant list of CAS properties for this feature, please review this guide.
You will need to map CAS settings to ZooKeeper’s nodes that contain values. The parent node for all settings should
match the configuration root value provided to CAS. Under the root, you could have folders such
as cas, cas,dev, cas,local, etc where dev and local are Spring profiles.
To create nodes and values in Apache ZooKeeper, try the following commands
as a sample:
1
2
3
4
5
zookeeper-client -server zookeeper1:2181
create /cas cas
create /cas/config cas
create /cas/config/cas cas
create /cas/config/cas/settingName casuser::Test
Creating nodes and directories in Apache ZooKeeper may require providing a value. The above sample commands show that
the value cas is provided when creating directories. Always check with the official Apache ZooKeeper guides. You may not need to do that step.
Finally in your CAS properties, the new settingName setting can be used as a reference.
1
# cas.something.something=${settingName}
…where ${settingName} gets the value of the contents of the Apache ZooKeeper node cas/config/cas/settingName.
Amazon S3
CAS is also able to use Amazon S3 to locate properties and settings.
Support is provided via the following dependency in the WAR overlay:
CAS is also able to use Microsoft Azure’s KeyVault Secrets to locate
properties and settings. Support is provided via the following dependency in the WAR overlay:
To see the relevant list of CAS properties for
this feature, please review this guide.
IMPORTANT: The allowed name pattern in Azure Key Vault is ^[0-9a-zA-Z-]+$. For properties that contain
that contain . in the name (i.e. cas.some.property), replace . with - when
you store the setting in Azure Key Vault (i.e. cas-some-property).
The module will handle the transformation for you.
By default, settings are expected to be found under a CAS_SETTINGS_TABLE that contains the fields: id, name and value.
To see the relevant list of CAS properties for this feature, please review this guide.
REST
CAS is also able to locate properties and settings using a REST API.
Support is provided via the following dependency in the WAR overlay:
The REST endpoint is expected to produce a Map in the payload with keys as the setting names
and values as the setting value. To see the relevant list of CAS properties for this
feature, please review this guide.
CAS Server Cloud Configuration
The cloud configuration modules provided above on this page by the CAS project directly may also be used verbatim inside
a CAS server overlay. Remember that the primary objective for these modules is to retrieve settings and properties
from a source. While they are mostly and primarily useful when activated inside the Spring Cloud Configuration server and
can be set to honor profiles and such, they nonetheless may also be used inside a CAS server overlay directly to
fetch settings from a source while running in standalone mode. In such scenarios, all sources of configuration regardless
of format or syntax will work alongside each other to retrieve settings and you can certainly mix and match as you see fit.
Composite Sources
In some scenarios you may wish to pull configuration data from multiple environment repositories.
To do this just enable multiple profiles in your configuration server’s application properties or YAML file.
If, for example, you want to pull configuration data from a Git repository as well as a SVN
repository you would set the following properties for your configuration server.
In addition to each repo specifying a URI, you can also specify an order property. The order property allows you to specify
the priority order for all your repositories. The lower the numerical value of the order property the
higher priority it will have. The priority order of a repository will help resolve any potential
conflicts between repositories that contain values for the same properties.
Property Overrides
The configuration server has an “overrides” feature that allows the operator to provide configuration properties
to all applications that cannot be accidentally changed by the application using the normal change events and hooks.
To declare overrides add a map of name-value pairs to spring.cloud.config.server.overrides.
For example:
1
2
3
4
5
6
spring:cloud:config:server:overrides:foo:bar
This will cause the CAS server (as the client of the configuration server) to read foo=bar independent of its own configuration.
To lean more about how CAS allows you to reload configuration changes,
please review this guide.
Clustered Deployments
CAS uses the Spring Cloud Bus
to manage configuration in a distributed deployment. Spring Cloud Bus links nodes of a
distributed system with a lightweight message broker. This can then be used to broadcast state
changes (e.g. configuration changes) or other management instructions.
